home *** CD-ROM | disk | FTP | other *** search
/ Amiga News 95 / Amiga News 95.iso / dpat / dpat05 / diskfixer / diskfixer.doc < prev    next >
Text File  |  1990-01-17  |  15KB  |  329 lines
  1.                             D I S K   F I X E R
  2.  
  3. L'utilitaire pour réparer les disquettes que tout le monde attendait!!!
  4.  
  5.                               Auteur: Cédric BEUST
  6.  
  7.  
  8.      L'idée d'écrire un réparateur de disquettes m'est venue après avoir
  9. fait des statistiques sur la cause des Read/Write Errors qui arrivent
  10. quelquefois aux disquettes. La constatation était affligeante: dans plus
  11. de la moitié des cas, les données étaient intactes mais l'AmigaDos
  12. refusait obstinément de les lire sous prétexte que l'un des checksums
  13. était incorrect.
  14.  
  15.      Je me suis donc rebiffé et le résultat est le Disk Fixer.
  16.  
  17.  
  18.      CE QUE CE PROGRAMME FAIT:
  19. :-)       Il répare dans environ 50% des cas (en fait je pense que c'est
  20.           plus mais je préfère ne pas trop m'avancer) les disquettes
  21.           endommagées avec un taux de rattrapage de 100%
  22.  
  23.      CE QU'IL NE FAIT PAS:
  24. :-{       Des miracles! Si les pistes sont véritablement illisibles, il ne
  25.           tentera pas de deviner ce qu'il s'y trouvait avant que le drive
  26.           fasse de la gravure sur la disquette. De toutes façons, dans ce
  27.           cas, aucun utilitaire ne pourrait récupérer les données perdues.
  28.  
  29.      Contrairement aux utilitaires de réparation couramment répandus
  30. (DiskDoctor, DiskSalv...) qui se contentent de répertorier les pistes
  31. endommagées et de les contourner en ramassant les morceaux, Disk Fixer (df
  32. pour les intimes) essaiera directement de réparer la piste endommagée en
  33. analysant les données brutes (Raw Data). Je vais y revenir. Il ne fait
  34. donc aucune modification de la BitMap, ni de quoi que ce soit concernant
  35. le Dos.
  36.  
  37.      Ce dont vous avez besoin:
  38.        - deux drives (une version future pourrait travailler avec un
  39.          seul)
  40.        - la disquette endommagée dans le drive source
  41.        - une copie de cette disquette dans l'autre. Cette copie peut être
  42.          faite avec n'importe quel copieur (même DiskCopy). La piste
  43.          endommagée ne sera pas copiée dans ce cas mais sera mise à zéro.
  44.          C'est là que le Disk Fixer entre en action.
  45.  
  46.      J'ai essayé dans la mesure du possible de rendre ce programme
  47. accessible à tous, même sans savoir ni comprendre ce que je vais essayer
  48. d'expliquer. Ces explications ne sont là que pour pallier une éventuelle
  49. défaillance du programme, afin que l'utilisateur puisse faire la
  50. réparation lui-même le cas échéant. Elles ne sont pas vraiment
  51. indispensables dans la mesure où l'incompréhension du tableau d'analyse
  52. n'exclut nullement une réparation de la disquette, même par un débutant
  53. (menu Réparer).
  54.  
  55.  
  56.           Qu'est-ce qu'une piste brute (Raw Track)?
  57.  
  58.      Il y a deux niveaux de visualisation de la disquette. Le premier est
  59. celui que vous obtenez en utilisant un éditeur de disquette (Mirror Hack,
  60. DiskWik, NewZap, etc...). Pour des raisons matérielles, il n'est pas
  61. possible d'écrire directement ces données telles quelles sur la disquette,
  62. car le drive ne pourrait plus les relire. Il faut donc les coder avant de
  63. les écrire. Le système de codage employé par l'Amiga est le MFM. Je ne
  64. vais pas m'étendre là-dessus car cela ne présente pas d'intérêt pour le
  65. présent sujet. Ce codage revient finalement à doubler la taille des
  66. données. Autrement dit, un secteur, qui fait 512 octets, sera codé en
  67. 1024. En fait, il y en a plus, car il faut faire précéder ces données d'un
  68. tas d'informations afin que le Dos s'y retrouve. Il y donc deux champs sur
  69. une Raw Track: champ Header et champ Data.
  70.  
  71.      Le champ Header:
  72.           Octets avant synchronisation:          AAAA AAAA
  73.           Deux mots de synchronisation:          4489 4489
  74.           Partie info (voir plus bas):           xxxx xxxx xxxx xxxx
  75.           Partie inutilisée:                     16 * xxxx
  76.           Checksum header:                       xxxx xxxx xxxx xxxx
  77.           Checksum data:                         xxxx xxxx xxxx xxxx
  78.                                                  -------------------
  79.                                                  32 mots
  80.  
  81.      Le champ Data:
  82.           Datas:                                 1024 octets (512 mots)
  83.  
  84.      Donc, la longueur totale d'une piste (en octets) est
  85.  
  86.           (64 + 1024) * 11 = 11968 ($2ec0)
  87.  
  88.      A cela il faut rajouter l'intervalle de piste (gap) dont la longueur
  89. est variable (environ $2b8).
  90.  
  91.                Total: environ $3178 octets ($18bc mots)
  92.  
  93.      La partie info du champ Header contient plus de précision à propos de
  94. ce qu'on va trouver: par exemple, on pourrait lire (une fois décodé. Le
  95. même codé prendrait 4 mots au lieu de 2)
  96.  
  97.           Info:          ff0b0305
  98.  
  99.      Avec respectivement
  100.           - ff: Identificateur de format (toujours $ff pour Amiga)
  101.           - 0b: Numéro de piste. Attention: en fait il s'agit de la piste 
  102.            multipliée par deux plus la tête. Ainsi, ici, c'est la piste 5, 
  103.            tête 1
  104.           - 03: Numéro de secteur
  105.           - 05: Nombre de secteurs avant d'atteindre l'intervalle de piste
  106.  
  107.      Ces précisions étant faites, voyons ce que fait le Disk Fixer.
  108.  
  109.  
  110.      Ce que fait le Disk Fixer
  111.  
  112.      Tout d'abord, il permet d'analyser une piste en affichant un tableau
  113. qui pourrait ressembler à celui-ci:
  114.  
  115.                   Analyse de la piste 5 tete 1
  116.  
  117.           Header    Etat   Chk. lu  Etat  Chk. lu  Etat
  118.           --------- ---- ---------- ---- --------- ----
  119.             ff0b000b  OK       40004  OK   51544551  OK  
  120.             ff0b010a  OK       40105  OK   45044440  OK  
  121.             ff0b0209  OK       40105  OK    1041514  OK  
  122.             ff0b0308  OK       40004  OK   55110504  OK  
  123.             ff0b0407  OK       40404  OK   11114411  OK  
  124.             ff0b0506  OK       40505  OK   11554441  OK  
  125.             ff0b0605  OK       40505  OK   54441451  OK  
  126.             ff0b0704  OK       40404  OK   11501501  OK  
  127.             ff0b0803  OK       40400  OK   54041401  OK  
  128.             ff0b0902  OK       40501  OK   44401000  OK  
  129.             ff0b0a01  OK       40501  OK    4015505  OK  
  130.  
  131.           Longueur: 315e
  132.  
  133.      A la lumière des explications précédentes, la signification de tout
  134. ceci devrait être évidente: dans le champ "Header" se trouve le décodage
  135. de la partie info, dans la partie "Chk.lu" des deux champs se trouve la
  136. valeur du checksum qui est écrite sur la disquette, et la colonne "Etat"
  137. vous donne le résultat de la comparaison de cette valeur lue avec celle
  138. que le programme a calculée lui-même (si ces deux ne sont pas égales, vous
  139. aurez un "**" à la place de "OK").
  140.  
  141.  
  142.      Comment savoir si la piste est réparable?
  143.  
  144.      Les affichages suivants indiquent des données que l'on peut
  145. récupérer:
  146.  
  147.            Header    Etat   Chk. lu  Etat  Chk. lu  Etat
  148.           --------- ---- ---------- ---- --------- ----
  149.             aa0b000b  **       40004  OK   51544551  OK  
  150.             12340178  **       40105  OK   45044440  OK  
  151.             ff0b0209  OK       40105  **    1041514  OK  
  152.             ff0b0308  OK       40004  OK   55110504  **  
  153.             ff0b0407  OK       40404  OK   11114411  OK  
  154.             ff0b0506  OK       40505  OK   11554441  OK  
  155.             ff0b0605  OK       40505  OK   54441451  OK  
  156.             ff0b0704  OK       40404  OK   11501501  OK  
  157.             ff0b0803  OK       40400  OK   54041401  OK  
  158.             ff0b0902  OK       40501  OK   44401000  OK  
  159.             ff0b0a01  OK       40501  OK    4015505  OK  
  160.  
  161.      Seuls les 4 premiers secteurs sont en mauvais état. Or les mauvaises
  162. valeurs peuvent être recalculées facilement:
  163.  
  164. -  pour la partie info, Disk Fixer ignore simplement ce qu'il lit et
  165. reconstitue lui-même l'identificateur de secteur ($12 -> $ff), le numéro
  166. de piste ($34 -> $0b), et l'intervalle de piste ($78 -> $0a). Remarquez
  167. que dans la version actuelle, il ne tente pas de réparer le numéro de
  168. secteur. Pour vous, il est facile de voir que celui qui manquerait serait
  169. $01 (ça part de 0 et ça croît jusqu'à $0a), car ici c'est simple. Mais
  170. imaginez une piste dans laquelle les numéros seraient 3, 8, 4, 1, ??, 7,
  171. etc... ça devient beaucoup plus dur de déterminer lequel manque. Et je
  172. laisse volontairement de côté le cas où des numéros se retrouvent
  173. plusieurs fois: comment savoir lequel on doit choisir? Ici, c'est à
  174. l'utilisateur d'analyser la piste et de la modifier en recodant les
  175. données qu'il aura calculées (la version 2.0 de df ne permet pas de
  176. modifier le buffer, seulement de le visualiser. Une version future le
  177. permettra, et pourra vraisemblablement calculer dans le mesure où c'est
  178. possible, le secteur manquant)
  179.  
  180. -  pour la partie checksum, le calcul se fait simplement (suite de XOR
  181. principalement), et il est facile de récrire un checksum correct (de la
  182. même façon que précédemment, df ignore le checksum lu et écrit celui qu'il
  183. a calculé)
  184.  
  185.      En revanche, il y a fort à parier qu'une piste ayant le schéma
  186. suivant soir irrémédiablement perdue:
  187.  
  188.         Analyse de la piste 0 tete 1
  189.  
  190. Header    Etat   Chk. lu  Etat  Chk. lu  Etat
  191. --------- ---- ---------- ---- --------- ----
  192.  ff010407  OK       10404  OK   40001555  OK  
  193.  ff010506  OK       10505  OK   10514400  OK  
  194.  ff010605  OK       10505  OK   40044414  OK  
  195.  ff010704  OK       10404  OK   14540451  OK  
  196.  ff010803  OK       10400  OK    4540455  OK  
  197.  ff010902  OK       10501  OK   50441144  OK  
  198.  ff010a01  OK       10501  OK   44145010  OK  
  199.  ffffffff  **    ffffffff  **   ffffffff  **  
  200.  fff23815  **    303e000c  **   10000004  **  
  201.  234c2f7c  **    15bc2200  **     a80abc  **  
  202.       220  **         a29  **         18  **  
  203.  
  204. Longueur: 315c
  205.  
  206.      Ici, le carnage est évident: plus de la moitié de la piste ne peut
  207. pas être analysée, car df n'a même pas trouvé les bits de synchronisation
  208. ($44894489). Si vous essayez de réparer une telle piste, il y a fort à
  209. parier que df en sera incapable et qu'il formattera la piste destination.
  210.  
  211.  
  212.      Description de l'utilisation de Disk Fixer
  213.  
  214.      Au départ, vous verrez trois fenêtres s'ouvrir: l'une pour afficher
  215. le tableau d'analyse, l'autre est une grille pour savoir sur quelle piste
  216. on se trouve et lesquelles on a déjà analysées, et la dernière est une
  217. petite fenêtre dans laquelle apparaissent des messages divers.
  218.  
  219.      Il y peu de menus et ceux-ci sont explicites:
  220.  
  221. - Analyse:
  222.      Vous pouvez ainsi analyser le buffer de la piste courante, lire une
  223. piste que vous précisez, lire la piste suivante, la précédente ou encore
  224. relire la présente, et remettre la grille à zéro.
  225.  
  226. - Analyse du buffer:
  227.      Un nouveau menu apparaît. Il vous permet de décoder en MFM les deux
  228. mots longs à partir du curseur (c'est-à-dire celui qui est encadré, et le
  229. suivant). Le résultat du décodage s'affiche en titre de la fenêtre. Vous
  230. pouvez également calculer le checksum du Header (c'est-à-dire des 64
  231. octets à partir du curseur) ou du champ Data (1024 octets).
  232.  
  233.      Pour vous déplacer dans le buffer, vous disposez des commandes
  234. suivantes:
  235.  
  236.      * Sur le pavé numérique, 2 4 6 8 pour vous déplacer d'un mot long (ou 
  237.     les flèches)
  238.      * 3 et 9 pour avancer d'une page
  239.      * ESC pour quitter la visualisation
  240.  
  241. - Réparation:
  242.      C'est une opération dangereuse car elle risque de détruire la
  243. disquette destination. Faites donc bien attention. Vous pouvez réparer
  244. soit une piste unique (celle qui est affichée) soit un intervalle de
  245. piste, auquel cas les bornes vous sont demandées.
  246.  
  247.      L'esprit de Disk Fixer est d'obtenir quel que soit le résultat une
  248. disquette destination entièrement lisible à l'arrivée (du moins, sur les
  249. pistes traitées). Ainsi, s'il n'arrive pas à récrire une piste
  250. correctement, il formattera la piste destination (vous serez prévenu par
  251. un 'F' dans la grille). Je ne sais pas si c'est une bonne chose. A vous de
  252. m'en faire part.
  253.  
  254.      Signification des lettres inscrites sur la grille:
  255.  
  256.           '.'     Ecriture fidèle réussie     'L'     Lecture en cours
  257.           'E'     Ecriture en cours           'F'     Piste formattée
  258.           'V'     Vérification en cours       '?'     Erreur de formattage
  259.  
  260. - Sélection des drives:
  261.      Pas de commentaire, si ce n'est qu'un flash vous avertira de
  262. l'interdiction de sélection de tel ou tel drive.
  263.  
  264.  
  265.      Améliorations possibles dans le futur
  266.  
  267. - Autoriser la modification du buffer par l'utilisateur, et que le nouveau
  268. buffer puisse être écrit sur la disquette
  269. - Toujours dans l'analyse du buffer, fournir tous les outils nécessaires
  270. pour faire le codage dans les deux sens (pour l'instant, seul le MFM ->
  271. Normal est fait). Par exemple, l'utilisateur pourra rentrer ff0b0102 et le
  272. programme se chargera de coder ceci comme il faut, et de recalculer le
  273. checksum
  274. - Nouvelles fonctions de déplacement (début, fin, etc...)
  275. - Autorisation d'utiliser un seul drive, et donc interruption pour
  276. demander à l'utilisateur d'insérer la disquette destination
  277. (éventuellement, prévoir que les disquettes source et destination puissent
  278. être identiques, encore que cela soit tellement dangereux que je n'en vois
  279. pas l'intérêt. J'y réfléchirai).
  280.  
  281.  
  282.      Remerciements
  283.  
  284. -  La totalité de Disk Fixer est écrite en C (sauf trois lignes en
  285. Assembleur), et plus précisément avec le Lattice 5.0. Grand merci à
  286. l'éditeur LSE et au superbe - quoiqu'un peu gourmand gourmand en mémoire -
  287. debugger CPR
  288.  
  289. -  Un grand merci à Power Windows (enfin, ses auteurs) sans lequel le
  290. travail avec Intuition ne serait pas ce qu'il est. Il est d'ailleurs
  291. probable que sans PW la version 2.0 n'aurait jamais vu le jour (la version
  292. 1.0 était une banale fonction CLI). Mais il y a un bug dans PW dès qu'on
  293. veut ouvrir une quatrième fenêtre lors de la génération de code. Résultat:
  294. j'ai dû utiliser deux fichiers de génération.
  295.  
  296. -  Une offrande particulière au gurubuster GOMF 3.0 qui n'a pas chômé
  297. pendant l'écriture de ce programme!
  298.  
  299. -  Remerciements aux testeurs éclairés qui font que ce programme génial
  300. est devenu un programme sublimement génial: Cédric Nérot, Ludwig Neumann,
  301. Bruce Lepper, Jean-Charles Godien, etc...
  302.  
  303.  
  304.         J'espère sincérement que ce programme sera utile.
  305.        N'hésitez pas à me joindre pour m'adresser vos remarques:
  306.  
  307.  
  308.                            Cédric  BEUST
  309.                             'Prométhée'
  310.                      80, Av. du Bois de Cythère
  311.                             06000  NICE
  312.  
  313.                          Tél. 93 96 00 23
  314.  
  315.  
  316. --- Nouvelles versions
  317.  
  318. 2.1 (3 Novembre 1989):
  319.   Dans la forme, peu de changements, si ce n'est le numéro de version. En 
  320.   revanche, j'ai récrit toutes les routines concernant l'analyse du     
  321.   buffer (longueur, calcul du checksum, réparation, etc...) en        
  322.   Assembleur. C'est ce que j'aurais dû faire dès le début car j'ai     
  323.   directement recopié les routines de la ROM. J'ai également simplifié    
  324.   l'affichage des messages dans la fenêtre (plus de longueur ni de type   
  325.   d'erreur. Une idée qui me trotte dans la tête pour une version future:  
  326.   ajouter une option "vérifier la disquette"). Enfin, j'ai quelque peu    
  327.   amélioré l'algorithme de réparation qui est légèrement plus efficace    
  328.   que le précédent.
  329.